【書評】「進化的アーキテクチャ」を読みました
サーバーレス開発部の阿部です。
もとよりアーキテクチャにまつわる話は好きな方なのです。今までの仕事でもアーキテクチャが様々な制約のバランスをとってハマった時の気持ちよさと言ったらないですよね。それに比べてハマらなかった時の惨めさと言ったら。とっととセカンドシステム作りたくなってしまいます。
アーキテクチャの変更は実行環境の技術要素やミドルウェアなど影響範囲が多岐に渡ることもあって、なかなか手をつけづらいものという印象があります。プログラムはテストで守ることによってリファクタリングが可能になり変化を許容しやすくなる、ではアーキテクチャは？という問いに対して答えようとする本を読みました。それが今日ご紹介する「進化的アーキテクチャ」です。
進化的アーキテクチャとは何か？
まずはこの本の定義を引用(強調筆者)します。
進化的アーキテクチャとは、複数の次元にわたる漸進的で誘導的な変更を支えるものである
全てのアーキテクチャに共通する正解はなく、ビジネスドメインや実行環境などの影響下で、目的を達成するための各種特性のバランスを取りながら決定されるものです。それら特性の中にはトレードオフや相関の関係にあるもの様々あり、それがアーキテクチャという概念を複雑にしています。
進化的アーキテクチャは、これら特性のバランスに対して「適応度関数」と呼ばれる特性評価のための指標を設定し、デプロイパイプラインに組み込むことで是正のタイミングを検知しようというライフサイクルを包含した取り組みです。上記定義の中で「誘導的」と表現されている変更はこの「適応度関数」への適合度合いに向けた変更と位置付けられます。
また、これらの変更をしやすい状況を作るために、アーキテクチャの分割をし、デプロイ可能な単位を小さく保つ活動が必要です。この活動には実際のコンポーネントの結合に加えてデータの分割なども含まれます。これが、上記定義の中で「漸進的」と表現されている変更となります。
ライフサイクルを包含した概念なので、その実施にあたっては継続的デリバリーのプラクティスとの親和性が高いようです。本書の中でも度々言及がありました。
ちょっとこれは、な点
- 特に1章から2章の図がわかりづらい、もっと描くべきポイント変えたほうが理解しやすいかと
- (仕方ないけど)実例が薄く抽象的なので、厚さの割には理解に時間がかかる
よかった点
- 疎結合を邪魔する無理な重複排除するな、という考え方(ドメイン
- コンウェイの法則、逆コンウェイの法則戦略
- 「楽しいメタ作業であるという理由だけでアーキテクチャを構築してはいけない」という耳の痛いお言葉
まとめ
アーキテクチャ関連の本らしく、「これだ！」という答えは提示してくれないわけですが、非常に興味深い内容でした。アーキテクチャの歴史的な背景などにも触れられていて、Enterprise Service Bus懐かしい、とか思って読んでました。コンウェイの法則に触れている通り、最終章の実践では取り組むためのチームのあり方やビジネスとの付き合い方にも触れている点も良い評価ポイントだと思います(余談ですが、この章に出てくる「コンサルティング柔道」という単語センスに惚れました)。
また、サーバーレスアーキテクチャについても触れられており、進化的であるために注意すべきポイントが書かれていたのは大きな収穫でした。
